AWSの運用ベストプラクティス 「運用上の優秀性(Operational Excellence)」についてがっつり説明しているスライドがあったのでレポートします

AWS が公開している「アーキテクチャに関するベストプラクティス」、Well-Architected (W-A) フレームワークには、運用（オペレーション）に関する記述も当然あります。

• AWS Well-Architected – 安全で効率的なクラウド対応アプリケーション

「運用上の優秀性（Operational Excellence）」と銘打たれているそれは、フレームワークを支える5つの柱のうちのひとつであり、「ビジネス価値を提供するためのシステムの実行とモニタリング、および継続的にプロセスと手順を改善することに焦点を当て」たものと説明されています。AWS を利用している組織の運用担当者であれば、いちどは目を通しておきたいものです。

・・・なのですが、

少々残念なことに、この「運用上の優秀性についてのホワイトペーパー」は、'18/06 時点で英語版しかありません。A4 25ページにわたってぎっしり書かれているので、訳して紹介するにしても分量があります。

なにか代替となる資料がないか。。と探していたところ、下記のスライドを見つけました。スライドであれば紹介もしやすいと考えたのでお届けします。

• AWS Well-Architected Framework: Operational Excellence Pillar

かなり超訳しているところがあるので、もとのスライドと見比べながら見て頂けますと幸いです。

スライド

• Jonathan LaCour
• CTO of Reliam
• テクノロジスト
• プログラマ
• クラウドストラテジスト
• バーボン好き
• Reliam社の紹介
• Managed Cloud Services - AWS - Microsoft Azure | Reliam
• "Reliam is an AWS certified consulting and managed services provider based in Southern California."
• AWS コンサルティングパートナー
• Q : あなたの会社はいまAWSを使っていますか？

Agenda

• W-Aの紹介
• Operational Excellenceのデザイン原則
• Operational Excellenceの領域
• Preparation
• Operation
• Evolution
• Q&A

The Well-Architected Framework

• W-Aの5つの柱
• Operational Excellence (運用上の優秀性)
• オペレーショナル・エクセレンス - Wikipedia
• Security (セキュリティ)
• Reliability (信頼性)
• Perfoemance Efficiency (パフォーマンス効率)
• Cost Optimization (コストの最適化)
• W-Aの価値
• 素早い構築とデプロイ
• 低い、または緩和されたリスク
• 情報に基づく決定
• AWSベストプラクティスからの学び
• Reliam's Insights from W-A Reviews
• Promotion - AWS Well-Architected Review - Archive | Reliam
• Reliamの提供するW-A Reviewパッケージの実績
• クリティカルな事象の92%がセキュリティ
• 69%が可用性および運用(オペレーション)
• ReliamはW-A Reviewパッケージを加速する
• Review - Free

「オペレーショナルエクセレンス」

• デザイン原則
• コード化されたオペレーション実行
• 注釈の付いたドキュメント
• 繰り返される、小さな、可逆的な変更
• オペレーション手順を繰り返しリファインする
• 障害を予測する
• 全ての「運用上の失敗」から学ぶ

コード化されたオペレーション実行

• "Perform operations as code"
• 「ソフトウェアエンジニアの経験」と「コード化されたオペレーション」
• ソフトウェアエンジニアの経験
• 自動化されたテスト
• CI/CDパイプライン
• バージョンコントロール
• コードレビューとコーディング標準
• コード化されたオペレーション
• 全て はソフトウェアである
• ソフトウェアの知見をオペレーションとインフラへ
• リスク回避、確実な一貫性
• Q : あなたの組織は Infrastructure as Code に適合していますか？

注釈の付いたドキュメント

• "Annotated documentation"
• 「オンプレミス環境」から「クラウド環境」へ
• オンプレミス環境
• 人の手によるドキュメント作成
• エラーを起こしがち
• ドキュメントと実装の乖離
• 運用の迅速性に悩む
• クラウド環境
• 自動化されたドキュメント生成
• 人間 と システム の両方に使いやすい
• ドキュメントは実装を反映している
• 運用の迅速性を拡大する

繰り返される、小さな、可逆的な変更

• "Frequent, small, reversible changes"
• 「従来型のアプローチ」から「継続的アプローチ」へ
• 従来型のアプローチ
• 大きな、リスクの高い変更の束を抱えたソフトウェアリリース
• アジャイル経験者は多くの「スプリント」をひとつのリリースに詰め込む
• システムは単一的（モノリシック）
• 継続的アプローチ
• 変更することは普通のことになる
• 小さく特化されたコンポーネントの集合体であるシステム
• 全ての変更は素早く切り戻すことが可能にデザインされている
• Q : 一般的なリリースの頻度は？

オペレーション手順を繰り返しリファインする

• 「ソフトウェアエンジニアリングのやり方」と「運用のやり方」
• ソフトウェアエンジニアリングのやり方
• 規則正しく実施される「振り返り」ミーティング
• 拡張は連続的に組み込まれていく
• 運用のやり方
• 規則正しく実施される「Game Day」とその振り返り
• 拡張は連続的に組み込まれていく
• Q : あなたの組織は継続的に「Game Day」を設けていますか？

※ Game Day = 実際に障害を発生させてその対策を行う、一種の訓練。システムの可用性機構が正常に動作すること（なのでサービスに影響は及ばない）の確認や、そういった事象が発生した時のオペレーションに担当者が習熟することが目的。

障害を予測する

• 「よくあるオペレーションチーム」から「優秀性を持ったオペレーションチーム」へ
• よくあるオペレーションチーム
• 受動的な障害へのアプローチ
• 全てが終わった後の「死体解剖(Post-mortem)」訓練
• 問題はいつも 本番環境から発見される
• 優秀性を持ったオペレーションチーム
• 能動的な障害へのアプローチ
• 「死体になる前の(Pre-mortem)」訓練
• Game Dayのシナリオを試験し、正常確認し、測定する
• 問題はいつも 予見される
• Q : 「死体になる前の」打合せを定期的に行っていますか？

全ての「運用上の失敗」から学ぶ

• 進化(Evolution)には共有(Sharing)が必要
• 共有による変化の推進
• 製品もマーケティングも財務も発展に巻き込む
• 継続的な進化という文化の確立

オペレーショナルエクセレンスの注力する領域(Area)

• Preparation - 準備
• Operation - 操作(オペレーション)
• Evolution - 進化

準備

オペレーション上の優先順位

• 成功しているオペレーションチームは精鋭である
• 彼らのワークロードのエキスパート
• ビジネス目標を把握している
• 自分の役割を明確に認識
• 規制およびコンプライアンス上の制約をしっかりと把握する
• コンテキストのない専門性の優先順位付けは不可能
• Q : あなたのオペレーションチームは「精鋭だ」と感じますか？

オペレーションのためのデザイン

• あえて、「開発」「更新」そして「運用」をデザイン側から熟考する
• コード化された「全て」
• スケジュールされたCI/CDパイプライン
• 標準的なツールとテンプレートの共有ライブラリ
• 偏執的に観測する - データだ、データをもっとよこせ！
• インシデント発生時に素早く動くための、あなた自身の能力

オペレーションの準備はできていますか？

• 技術は重要です、しかしそれは手順と手続きでしかありません
• 正確なドキュメンテーション
• チェックリスト、操作指示書(Runbook)、定石集(Playbook)
• よく訓練された「正しい」チーム
• 近道はない！
• 準備状態をコントロールする統治状態
• 手順と手続きを AWS でコード化する
• リソースタグ、イベントトリガ、AWS Systems Manager Run Command、AWS Lambda、CloudWatch Events 等
• Q : あなたのオペレーションチームは文書化された手順を持っていますか？

オペレーション

オペレーション上のシステムヘルスについて

• 「運用上の優秀性」は、即時に利用でき、正確な、ビジネス要件上の鍵となるメトリクスの分析を必要とする
• 性能、コスト、可用性、遅延　等
• データの収集・集積
• ダッシュボードや通知の作り込み
• AWSのこれらのツールを使う：
• CloudWatch、Amazon Elasticsearch Service / Kibana　その他

事象発生への対応

• キーメトリクス、通知、そしてダッシュボード、これらで「武装」したあなたのチームは自信を持ってそれらの事象に対処できる
• 優先順位を付ける際に、ビジネスインパクトを考慮する
• スクリプトは、データによっててこ入れされた「コード化されたオペレーション」を通して反応する
• 問題ないと判断されているバージョンへの自動ロールバック機能を作り込む
• Auto-Scalingと共にあれ (Embrace AWS auto-scaling)
• インシデントへの対処が全て終わった後、根本原因を分析するための「死体解剖」が行われる

進化

経験から学ぶ

• オペレーションチームの成功に関する最も優れた指標は何か？　学習への情熱だ。
• 全てのインシデントはチャンス(Opportunity)である
• オペレーションチームに、分析し、実験し、そして拡張することを奨励する
• AWSはそれらを可能にする大規模なプラットフォームを提供している
• ビジネスにおいて、あらゆる点で違う視点を持つことは、成長への新しい機会であると知っておくべきだ
• Q : あなたの組織は運用上のイベントをちゃんと見ていますか？

学びを共有する

• 多くの会社は多くの製品とオペレーションチームを持っている。成長文化を進めるために、広く学習成果をシェアしよう
• ベストプラクティスを共有するために、AWSプラットフォームを活用する
• CloudFormationテンプレート、Chefクックブック、Lambda function
• AWS IAMを使用し、権限とアクセスコントロールを行う
• 進化は、局所的な動きではない

まとめ

• AWS W-A は、ベストプラクティスの強力な資料集である
• W-A プログラムのパートナー（Reliamのような！）はあなたのビジネスの加速をお手伝いする
• (訳注) もちろん弊社もお手伝いします！
• Q&A

最後に

Well-Architected フレームワークは、クラウドアーキテクトがアプリケーション向けに実装可能な、最も安全かつ高パフォーマンス、障害耐性を備え、効率的なインフラストラクチャを構築するのをサポートする目的で開発されました。

AWS Well-Architected のLPにそう謳われているように、AWS、というよりクラウドインフラは、もちろんオンプレミスの延長として考えることもできますが、「クラウドインフラ」の特性を生かすことで、より良く (Well) 利用することが可能です。設計も開発もそうですし、セキュリティも、もちろん運用もそうです。せっかく AWS がベストプラクティスを公開しているのですから、皆さんも是非ご活用ください。